This guest post comes from AWS Container Advocate Alex Morgan, who serves as the Principal Platform Engineer at TechHub in the United States. Alex is passionate about technologies that enable rapid and frequent releases, believing that every code commit should seamlessly transition to production. You can connect with him on Twitter @alexmorgan.
In recent years, many teams have embraced Infrastructure as Code (IaC) to simplify infrastructure provisioning and maintain consistency across environments. However, using declarative templates can limit the adoption of familiar coding practices. If you’ve ever experienced the frustration of copying and pasting AWS CloudFormation templates from previous projects or even StackOverflow, you may find yourself questioning the reliability of those snippets. How do you implement improvements or security updates across your codebase? How can you effectively share best practices within your organization or the broader community?
Fortunately, AWS has introduced an exciting addition to AWS CloudFormation: the AWS Cloud Development Kit (AWS CDK) in beta.
What Makes the AWS CDK Special?
With the AWS CDK, you can now easily share your best practices for creating top-notch AWS CloudFormation templates across your team or with fellow developers. You also benefit from the collective wisdom of the community.
Consider Amazon DynamoDB. While it may seem straightforward to set up in AWS CloudFormation with just a few lines of code, the reality is more complex. Once you’re in production, you’ll need to account for automatic scaling, regular backups, and crucial alarms for relevant metrics. This can lead to hundreds of lines of code.
Now imagine you need to create another application that requires a DynamoDB database. Are you really going to copy and paste all that YAML code? What happens when you discover bugs in your template? Will you remember to fix them in both codebases?
With the AWS CDK, you can create a “construct” for a production-ready DynamoDB database, package it as an npm module, and share it within your organization or with others!
What is the AWS CDK?
To understand the AWS CDK, it’s essential to compare it to the declarative approach using YAML (or JSON). The CDK allows you to define your infrastructure imperatively. The primary language is TypeScript, though it supports several others as well.
Here’s an example of a simple “Hello World” application in AWS CDK:
import cdk = require('@aws-cdk/cdk');
import s3 = require('@aws-cdk/aws-s3');
class MyStack extends cdk.Stack {
constructor(parent: cdk.App, id: string, props?: cdk.StackProps) {
super(parent, id, props);
new s3.Bucket(this, 'MyFirstBucket', {
versioned: true
});
}
}
class MyApp extends cdk.App {
constructor(argv: string[]) {
super(argv);
new MyStack(this, 'hello-cdk');
}
}
new MyApp().run();
Applications are the root constructs and can be directly utilized by the CDK CLI to generate and deploy the AWS CloudFormation template. An application can consist of multiple stacks, which are deployable units containing information about the region and account. Additionally, it is possible to deploy various stacks to multiple regions simultaneously.
Stacks include constructs that represent AWS resources like DynamoDB tables or AWS Lambda functions. A library is a construct that typically encapsulates additional constructs, allowing for the creation of higher-level constructs that can also be reused. Because constructs are simply TypeScript (or any supported language), they can be packaged and shared using any package manager.
Constructs
Understanding constructs is crucial, as the CDK revolves around them. Constructs are organized in a hierarchical structure known as a construct tree, which you can think of in three levels:
Level 1: AWS CloudFormation Resources
This level provides a one-to-one mapping of existing resources and is auto-generated. It mirrors the resources you currently use in YAML and ideally, you won’t have to interact with these constructs directly.
Level 2: The AWS Construct Library
These constructs operate on an AWS service level. They are opinionated, well-architected, and created by AWS. They come with sensible defaults, making it easier to create AWS resources without diving into the nitty-gritty details.
For instance, to create a complete VPC with private and public subnets across all available Availability Zones, you could write:
import ec2 = require('@aws-cdk/aws-ec2');
const vpc = new ec2.VpcNetwork(this, 'VPC');
The AWS Construct Library includes helpful concepts, such as least privilege IAM policies, event-driven API actions, security groups, and metrics. For instance, IAM policies are automatically generated based on your intent. If a Lambda function subscribes to an SNS topic, a policy is created to permit the topic to invoke the function.
Level 3: Your Creative Constructs
This is where it becomes exciting. As mentioned, constructs have a hierarchical nature. At this level, you can develop your own Amazon ECS cluster construct that includes automatic node draining, scaling, and all the necessary alarms. Alternatively, you could create a construct for all the alarms needed for monitoring an Amazon RDS database. It’s your chance to innovate and share your constructs with the community.
Conclusion
It’s encouraging that AWS released the CDK while it was still in its early stages. The documentation is already quite good, but not everything is covered yet. Not all AWS services have a corresponding AWS Construct Library module (level 2); many only have the basic AWS CloudFormation constructs (level 1).
In my opinion, the AWS CDK represents a significant advancement, enabling you to reuse AWS CloudFormation code and share it with others. It simplifies the application of company standards and allows developers to focus on creating exciting features instead of writing tedious code. For more insights on AWS CDK, check out this blog post here, and for an expert view on the topic, visit this page. Additionally, for a visual understanding, you can watch this excellent resource on YouTube here.
Leave a Reply